1. Field of the Invention
This invention relates generally to computer operating systems boot sequence and initialization methods and apparatus.
2. Summary of the Related Technology
System Software as it's developed today is tied very closely with the particular Macintosh machines that it supports. In some cases, this makes a lot of sense since the system software has to interface with the hardware. In other cases, though, this is an artificial limitation. For example, System 6.0.5 doesn't support the Macintosh Classic because the Classic was released after System 6.0.5. However, since the Classic is so similar to previous machines, namely the Macintosh SE, System 6.0.5 would work just fine if it weren't for the check made by the boot code that prevents it from loading.
Frequently there will be changes to the hardware which require changes to the system software. In many cases, the changes needed in the system software are minor compared to the task of developing and releasing an entirely new version. But, in the past, there was no way to provide incremental changes without releasing a whole new version of system software. Thus, each new set of machines required a complete and separate software development effort.
Hardware support releases of system software are released later, and have higher versions numbers than the version on which the release was based. Customers perceive that the hardware support version is superior because it has a higher version number. Customers then want the newer version, even if they do not have one of the new machines that require the new software. Exacerbating the matter is the fact that hardware support releases often supply additional functionality, causing developers and customers to want the new release for all machines. Hardware support features are required by new machines, thus new software releases are required to implement small human interface elements. For example, System 6.0.5 could not ship with Classic because “About the Finder. . . ” would have called it a Macintosh SE and given it the wrong icon.
In the past, operating systems were developed with a particular processor and hardware environment in mind. System designers tailored the operating system to run on a particular processor and hardware configuration. While it has been considered good programming design methodology to take advantage of the underlying hardware architecture, the operating system was limited to the particular processor and hardware environment for which it was written. The operating systems were not portable. This was so because the operating system software had to interface with and control the computer system hardware. Although such operating systems may have operated satisfactorily on one particular type of processor, they would not run on another type of processor. As a result, prior operating systems were inflexible.
In the past, an entirely new version of the operating system software usually had to be developed for each new type machine. An individual development effort was required to code and release a new version of the operating system whenever a new processor or hardware configuration change was implemented. Such development efforts were usually very expensive and time consuming.
In order for the operating system to accommodate different hardware environments, system designers were usually forced to release a new version of the operating system when new hardware platforms became available. Many times, it did not take long for the latest version of an operating system to be upstaged by a newer version generated to accommodate a new hardware configuration. As an undesirable result of this, different versions of the same operating systems would proliferate.
Even in the absence of new hardware platforms using new machine designs, there were other changes in hardware that required changes to the system software. In many cases, the changes to the hardware were relatively minor compared to the task of developing and releasing an entirely new version of the operating system software. Nevertheless, these ad hoc efforts at system design negatively impacted engineering resources, quality control, marketing, and profitability. The proliferation of different versions of an operating system created significant difficulties for those attending to version control and documentation. The problems normally encountered in debugging software and beta testing were greatly exacerbated by the proliferation of different versions of operating system software.
In the past, attempts have been made to extend the functionality of an operating system software release by patching or implementing new functions. These functionally extensible patch files were sometimes referred to as “extensions.” For example, to add new functionality that allows an application program to play movies within a document, an attempt might be made to extend the system software functionality with an extension file. Extensions were sometimes referred to as “INIT” files, because of their file type in the Macintosh computer environment provided by Apple Computer, Inc. Extension files were patch files that relied on the system boot routine to bring up the system from a power on reset state to a fully operational state.
Patch files contained changes to system software that were called in and executed to augment system software after system initialization by the boot routine. These patch files would change code in the operating system to accommodate new machines, new hardware configurations, and to update system software in order to fix problems or add functionality after the release of a particular version of an operating system.
In addition to the above described problems, application programs that were written to run on a particular hardware platform might not run on later versions of the hardware, because the application program might not be compatible with the new version of the operating system required for a new hardware configuration different from that on which the application program was originally designed to run.
Further problems were created because the way that system programmers dealt with the inherent incompatibility between most underlying hardware architecture's sometimes had the undesirable result of imposing artificial limitations on the software. Typically, a status check of the hardware configuration would be performed by the operating system during the system start-up, or boot procedure. Oftentimes, an operating system designed to run on a first hardware platform would be prevented from loading onto a second slightly different platform, when the status check determined that the hardware platform was not the one that the operating system expected. The system would halt, even though the operating system might be capable of actually running on that slightly different hardware platform. Thus, the artificial barrier created by the common practice of performing such status checks would make operating systems that were designed to run on a particular hardware platform incompatible with any different hardware platform, regardless of the similarities between the two hardware platforms. Nevertheless, such status checks were often considered to be a necessity in order to prevent computer system crashes, because of the lack of portability between most hardware platforms.
Customers were often confused when numerous ad hoc versions of system software appeared on the market with higher version numbers than the one the customer had just purchased. Customers typically perceived software having a higher version number to be superior over software with a lower version number, even though the difference in version was only to accommodate hardware which the customer did not utilize. This practice also tended to raise customer concerns as to why frequent software revisions were being released.
The system software vendor must test its latest released version of operating system software with all existing computer hardware, past and present. Of course, as the number of different hardware systems increases, so does the requirement for software testing of new system software versions.
It is apparent from the above discussion of problems in conventional systems, that there is a need for an improved method and apparatus to accommodate new computer hardware developments with an existing software operating system.